Computer systems that are connected to a computer network, such as the Internet, and host services, and which run applications are inherently insecure and face threats of varying risk. In order to design and implement the necessary security measures so that the risks underlying deployments on or within computing infrastructures are eliminated or mitigated, it is necessary to constantly monitor these networks, detect threats, be able to assess the risk they impose and prepare the necessary countermeasures.
The effectiveness of the security measures of a computer system may be evaluated by performing a computer security audit in which various aspects of computer security are analyzed and evaluated. The security audit may include a penetration test, which is a process by which a security auditor attempts to gain unauthorized access to an infrastructure of a computer system network, applications, and users mimicking what an attacker does. The target of a penetration test can be all of these “attack vectors” or any subset, such as the web applications, the network devices, the client applications and its users, wireless communications, or other vectors.
In general, a penetration test is a service offered by skilled auditors that use security tools in combination with a multitude of ad hoc methods and tools, in order to mimic an attacker and gain unauthorized (i.e., not included in the implicit or explicit security policy) control of valuable assets in the target network. For example, an auditor will conduct the test from his computer that is placed outside of the network perimeter (e.g., anywhere in the Internet) and attempt to take control of the desktops inside the target network, and possibly pivot to access corporate file repositories. Alternatively, the auditor may sit in one of the different network segments inside the perimeter (e.g., in the same network where developers sit) and attempt to access the valuable information (e.g., the credit cards database—which should be of restricted access for the deployment to be compliant with the Payment Card Industry Data Security Standard (PCI DSS)—or the individual health data—which should be of restricted access for the deployment to be compliant with Health Insurance Portability and Accountability Act (HIPAA)).
Computing infrastructure deployments evolve, as new software is added or old software is updated, new hosts are added or removed, the network topology is changed, vulnerabilities are introduced and made public; the security posture of an organization varies. It is therefore common, to test the security of the network periodically. For example the PCI DSS compliance standard mandates that there is at least one penetration test a year and also whenever there is a significant change in the network.
On the other hand, security tests have been typically deemed costly and time-demanding. Nowadays, there is a trend on moving computing infrastructures into “the cloud” which in particular implies an outsourcing of IT resources. However, there is still no consensus in how to approach the security on these new infrastructures. As an example, the Federal Risk and Authorization Management Program (FedRAMP) has only recently started debating this.
Cloud Services
Cloud computing is an informal term that encompasses different computing architectures that allow the scaling of computer resources that are accessed remotely. An “infrastructure as a service” platform provides its users with the ability to dynamically and programmatically administer the computing resources in their infrastructure (and also the associated costs). The granularity of resources to administer is at the infrastructure level (e.g., machine instances, network traffic, routers, load balancers). In a “Platform as a Service” offering a solution stack is provided including an installed OS, programming platform, database, etc.
Cloud services use virtualization and other technologies that are not new. However, they are implemented and deployed in non-standard ways. For example, Amazon Web Services from Amazon, GoogleAppEngine from Google, Azure from Microsoft, Rackspace, GoGrid, and Flexiscale all have different offerings. Moreover, users of these approach the design and deployment of their infrastructures differently even within the same specific cloud vendor.
Amazon Web Services (AWS) is one of the biggest competitors in the Platform as a Service space. One of its products, Amazon Elastic Compute Cloud (Amazon EC2) “is a web service that provides resizable compute capacity in the cloud. It is designed to make web-scale computing easier for developers.”
These new technologies, or actually the novel use and assembly of technologies that have come to be known as “cloud computing,” present several (new) problems to assess the security posture of a cloud infrastructure.
Limitations of Penetration Testing and its Automation
There are several aspects and features of the penetration testing frameworks and tools that facilitate the rendered services or help to maximize the coverage of threats that can be discovered. For example:
a first aspect worth mentioning is related to the threat coverage, specifically the attack vectors that a penetration testing framework (or any set of security tools) covers: the more attack vectors it covers and combines the broader spectrum of threats the framework may detect and exercise. A small handful of multiple attack-vector penetration testing frameworks are available—and most of these are commercial tools with the exception of a single open-source tool. Several single attack-vector tools or penetration testing frameworks have been designed and are available as commercial or open-source tools. For example, the so-called “web-application attack vector” can be tested by several of these, including Nikto, Paros, WebScarab and Burpsuite. These tools can handle some of the security tests relevant to the web-application attack vector, but rarely allow for local information gathering that will allow the auditor to assess the underlying risk of the network vulnerabilities. Moreover, since the auditor cannot test other vectors (e.g., network attack vector), pivoting is out of the question for him. In this sense, the coverage of single-vector penetration-testing tools underlying penetration tests is limited.
Similarly, the coverage of a penetration test is affected by the so-called depth in which each attack vector is covered during the test. Explicitly, a security tool is only able to target a subset of all the vulnerabilities present in an attack vector; and when this portion is small (the tool does not delve deep into the attack vector), then coverage is impacted negatively.
A second aspect worth mentioning is in the expertise of the auditor executing the penetration test or the way in which this expertise is embedded in the automation of these Frameworks—starting from automating common and/or repetitive chores (e.g., testing the Internet-facing web applications) through scripts, to the complete automation of a penetration test. Some of the available tools handle some rudimentary scripting automation, but one or two handle what is known in the art as attack planning capabilities; namely, the ability to accept as input an objective a potential threat that an attacker could exercise (e.g., compromise this server).
A third relevant aspect is that of mobility. The penetration tests are executed by a penetration tester or auditor running these tools from a computing device—such as laptop computer. In order to mimic the different attacker profiles—for example, insider and external hacker—the auditor must place his computer (i.e., the computer that runs this software) at different spots in the network topology. Alternatively, he may install a software agent in a system or device that lies in this network segment. That is, there is a mobility requirement which is typically addressed by moving a laptop with the installed software from place to place—and later integrating the results—or by running the tests from different computers.
A fourth aspect is that related to the form factor in which these functionalities are provided. In order to run these tools or frameworks, the user has to acquire (e.g., buy and/or download) the tool, install it and configure it for his computer. If this auditor requires a functionality that is not present in the tool or framework he uses, he must then install a second tool or framework to do so. Further, if this tool is commercial, he must first buy the tool. Note that when deciding for this second tool, the penetration tester must take into account the three aspects discussed before. In any case, a new investment of resources (monetary or other) must be made. It may be the case that the return of investment from buying a new commercial tool, or even installing a free one, is prohibitive for a smaller IT or security department in an organization. In this case, the security department has to conform by choosing from a restrictive set of less powerful tools.
Moreover, cloud infrastructures themselves introduce new elements and therefore a network infrastructure that is deployed in a cloud computing infrastructure is liable to new kinds of vulnerabilities that cannot be exercised with the older tools and techniques, but require tools and expertise to specifically target this.
In view of the shortcomings discussed above, there is a need for a system and method for automated computer security compromise delivered as a service.